This may be ok here. Although it is unclear if others don't reopen/extend this class. If that isn't the case, and the output isn't unreasonably large. This may be fine.

@runspired / @krisselden and myself should powow soon to fixup the cost centers insides of creation (of first object when mixins need application) in ember's core_object. I believe there is a relatively clear path to improving that, that would just have mega leverage across the whole ecosystem. I also believe this can be used to help bridge the ES6 <=> CoreObject worlds. As they really are not very dissimilar.

@stefanpenner this isn't something others can extend, but it is something that could theoretically have been reached into, found, and reopened. Is there a list of ember-data addons that we generally search for private usage in? cc @bmac

(1.53ms => .97ms).

was this one sample?

@stefanpenner didn't you reopen this at Yapp for the subscribe stuff?

/cc @lukemelia

@stefanpenner didn't you reopen this at Yapp for the subscribe stuff?

Unclear, I do also share your concern this is risky relative to the value. (making mixin stuff faster, would have nice leverage...)

Also, the proto() is only doing work here because of lookupFactory extend.

As far as wins go, this one is pretty small, but one of hundreds of paper cuts we die from when out together.

I don't actually think the win here is in this small perf gain as much as it is in building a core set of primitives that don't depend on Ember unless they truly need to. If Ember.Object and lookupFactory do have their costs lowered, I'm still unconvinced that this would belong remaining one.

I just checked out the 47 Ember Data Adapter addons from ember observer into a directory and grepped for RecordArrayManager and found no matches. I think its unlikely that anyone is reopening the RecordArrayManager.

I've updated my search to include the https://emberobserver.com/categories/ember-data-extensions and still found nothing that references RecordArrayManager.

@runspired This great! Is there any way to get some more exhaustive benchmarks?

@chadhietala the benchmark runs for repeated iterations are roughly similar. Since we strip the classCallCheck I'd be surprised if the compiled output were larger vs equal or smaller than the compiled output for the Ember.Object version.

Would heavily prefer this to be feature flagged.

@fivetanley What is your thinking on why the feature flag for this change. In theory it should be invisible to users and doesn't provide and new functionality?

@bmac @fivetanley I think this is the sort of thing where if we send it out, and it breaks people's apps, its small and we just revert it. Don't think it warrants a flag.

cc @bmac @fivetanley for review and suggested next steps.

@runspired this just needs a rebase and should be good to merge.

@bmac rebased :)